Conceptually this proposal sounds similar to #3489 (live location sharing). That one uses a state event and reference relations though. Replacements strike me as a more intuitive solution though.

I agree the concept is similar to MSC3489 in that both stream incremental state. For live text, I believe m.replace on m.room.message is the most intuitive and compatibility‑friendly primitive: older clients already understand “edits” and will converge to the final content; supporting clients can render the intermediate states seamlessly. It also avoids adding a new event type purely for live typing and reuses the well‑understood edit aggregation path (per MSC2676 / spec).

IIUC the enforcement can only happen on the client side. This means clients would need a way to discover such global server policy?

In the draft I wrote “default is enabled (unless server policy states otherwise)”, which is ambiguous without a standard way to advertise that policy. I propose to clarify that the normative control here is room‑level via m.room.live_messaging; clients MUST honor it. Servers MAY reject live‑marked events in unencrypted rooms as a local policy, but there is no standardized discovery for a global ban, so it’s out of scope for this MSC. I’ll remove/adjust the “unless server policy states otherwise” wording to avoid implying a discovery mechanism that doesn’t exist

This is only possible in unencrypted rooms because org.matrix.msc4357.live is in content which is encrypted.

yep, feature still works end‑to‑end (supporting clients decrypt, detect the marker, and render progressively), but enforcement and special aggregation are client‑side only in E2EE. I’ll add an explicit “E2EE considerations” subsection stating that server‑side enforcement is only feasible in unencrypted rooms.

Does batching mean combining several updates into a single event replacement?

By batching I mean coalescing local interim changes and emitting a single m.replace update at a bounded cadence (e.g. every ~2–3s or at natural boundaries like end‑of‑word), rather than sending an event per keystroke. Each update still contains the full current content in m.new_content; there’s no special “multi‑update container”. I’ll tighten the wording to make this explicit.

Is it allowed to transition back from completion into live mode?

I intend completion to be terminal for that message. Once the final update (without the live marker) is sent, the live session is over. Further changes are normal edits; resuming live mode should be done by starting a new live message. Allowing a message to re‑enter live mode risks confusing clients (especially non‑supporting ones) that have already treated it as finalized. I’ll add a normative MUST‑NOT to make this explicit.

Implementation requirements:

• Client (sending)
• Client (receiving)